The potential benefits of collaboration technologies are typically realized only in groups led by collaboration experts. This raises the facilitator-in-the-box challenge: Can collaboration expertise be packaged with collaboration technology in a form that nonexperts can reuse with no training on either tools or techniques? We address that challenge with process support applications (PSAs). We describe a collaboration support system (CSS) that combines a computer-assisted collaboration engineering platform for creating PSAs with a process support system runtime platform for executing PSAs. We show that the CSS meets its design goals: (1) to reduce development cycles for collaboration systems, (2) to allow nonprogrammers to design and develop PSAs, and (3) to package enough expertise in the tools that nonexperts could execute a well-designed collaborative work process without training.
Research shows that under certain conditions, groups using collaboration technologies such as group support systems (GSS) can gain substantial improvements in the effectiveness and efficiency of their work processes. GSS, however, have been slow to develop self-sustaining communities of users in the workplace. Organizations that use collaboration technology may require two kinds of support: process support and technology support. Both types of support involve (1) design tasks (e.g., designing a work process and designing the technology to support the process), (2) application tasks (to apply the process and to use the technology), and (3) management tasks (to monitor and control the process and to oversee the maintenance of the technology). This paper explores how these tasks and associated roles can be anchored in organizations, and the relationship of task allocation patterns to the sustained use of collaboration technology in organizations.
Collaboration engineering is an approach for the design and deployment of repeatable collaboration processes that can be executed by practitioners without the support of collaboration professionals such as facilitators. A critical challenge in collaboration engineering concerns how the design activities have to be executed and which design choices have to be made to create a process design. We report on a four-year design science study in which we developed a design approach for collaboration engineering that incorporates existing process design methods, pattern-based design principles, and insights from expert facilitators regarding design challenges and choices. The resulting approach was evaluated and continuously improved in four trials with 37 students. Our findings suggest that this approach is useful to support the design of repeatable collaboration processes. Our study further serves as an example of how a design approach can be developed and improved following a multimethod design science approach.
eXtreme Programming (XP) is a well-known agile software development method. While a number of reports have been published on explaining the XP methodology and the perceived benefits when using XP for system development in recent years, less is known about the actual operationalization of the XP principles. This paper presents an action research study reporting on the experiences of implementing the XP methodology in a development project for a Web-based, distributed information system. The goal of this research was to increase the understanding of how to effectively operationalize XP techniques so that the system being developed catered to today's fast-paced technological environment by allowing the developers to respond quickly to innovative and changing requirements. Overall, the research indicates that most of the XP principles could be effectively implemented; however, three of the principles required modification (i.e., testing, pair programming, customer collocation). Several benefits resulted from the usage of XP. The rapid prototyping enabled information technology developers and users to clarify system requirements, communicate openly, quickly build rapport, and create an interface that was easy to use and learn. Further, the research found that where the technology was new or foreign to the development team and the user, the XP process was flexible enough to support several iterations of technology and produce prototypes in a timely manner. Pair programming appeared to work effectively and offer value; however, it is not always practically feasible.
Business process reengineering (BPR) projects have been carried out for many years, with varying degrees of success. Two key reasons for failure are distinguished from the literature: insufficient stakeholder involvement and poor analyses of the business processes. The purpose of this paper is to present a decade of field experiences with collaborative BPR. Nine BPR projects were executed and analyzed in detail, leading to the identification of 87 themes regarding the efficiency and effectiveness of the project. These themes were organized into 12 categories of lessons learned that provide insight into the "best practices" and together informed the evolution of the collaborative business engineering (CBE) approach to BPR. The CBE approach combines a BPR process with collaboration and simulation modeling support to address the above-mentioned reasons for failure in BPR. The field experiences show that the CBE approach can be successfully applied for BPR projects in real life.
Organizations must be creative continuously to survive and thrive in today's highly competitive, rapidly changing environment. A century of creativity research has produced several descriptive models of creativity, and hundreds of prescriptions for interventions that demonstrably improve creativity. This paper presents the cognitive network model (CNM) as a causal model of the cognitive mechanisms that give rise to creative solutions in the human mind. The model may explain why creativity prescriptions work as they do. The model may also provide a basis for deriving new techniques to further enhance creativity. The paper tests the model in an experiment where 61 four-person groups used either free-brainstorming or one of three variations on directed-brainstorming to generate solutions for one of two unstructured tasks. In both tasks, people using directed-brainstorming produced more solutions with high creativity ratings, produced solutions with higher average creativity ratings, and produced higher concentrations of creative solutions than did people using free-brainstorming. Significant differences in creativity were also found among the three variations on directed-brainstorming. The findings were consistent with the CNM.
Field research and laboratory experiments suggest that, under certain circumstances, people using group support systems (GSS) can be significantly more productive than people who do not use them. Yet, despite their demonstrated potential, GSS have been slow to diffuse across organizations. Drawing on the Technology Transition Model, the paper argues that the high conceptual load of GSS (i.e., understanding of the intended effect of GSS functionality) encourages organizations to employ expert facilitators to wield the technology on behalf of others. Economic and political factors mitigate against facilitators remaining long term in GSS facilities that focus on supporting nonroutine, ad hoc projects. This especially hampers scaling GSS technology to support distributed collaboration. An alternative and sustainable way for organizations to derive value from GSS lies in an approach called 'collaboration engineering': the development of repeatable collaborative processes that are conducted by practitioners themselves. To enable the development of such processes, this paper proposes the thinkLet concept, a codified packet of facilitation skill that can be applied by practitioners to achieve predictable, repeatable patterns of collaboration, such as divergence or convergence. A thinkLet specifies the facilitator's choices and actions in terms of the GSS tool used, the configuration of this tool, and scripted prompts to accomplish a pattern of collaboration in a group. Using thinkLets as building blocks, facilitators can develop and transfer repeatable collaborative processes to practitioners. Given the limited availability of expert facilitators, collaboration engineering with thinkLets may become a sine qua non for organizations to effectively support virtual work teams.
Cross-cultural group support systems (GSS) field studies are scarce. Although the state of knowledge and theory development in this area warrants a focus on descriptive field explorations, most cross-cultural GSS research has taken place in laboratory environments. The study reported here represents the first detailed descriptive field study of GSS application in Africa. A grounded theory approach was used to collect and analyze data on eleven projects in which GSS meetings were organized in Malawi, Zimbabwe, and Tanzania. From the data emerged a model of GSS acceptance in the cultures investigated that extends the Technology Acceptance Model (TAM) in terms of a specification of a number of relevant external factors. These factors include the endorsement of top management, computer literacy, oral communication preference, referent power, and satisfaction with use. Furthermore, the findings suggest that there is potential for applying GSS in Africa to support capacity-building efforts, which tops the agenda of international development agencies.
In an action research study at the Amsterdam Municipal Police Force, a collaborative business engineering approach was employed to explore the joint application of group support systems and animation techniques to support stakeholder involvement in organizational change processes. Stakeholders constructed and evaluated static and dynamic models of the police force's current and future work processes. Findings illustrate the complimentary potential of the two technologies to support stakeholder involvement in terms of efficiency, resulting model quality, and stakeholder satisfaction with process and technologies. The study illustrates the value of an incremental modeling strategy, the involvement of a substantial number of stakeholders, and the need to keep the momentum in the process. Issues for further research concern the development of a collaborative modeling environment that allows for group enabled model construction and viewing and the automatic transformation between different types of models.